home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-dns-ixfr-00.txt < prev    next >
Encoding:
Text File  |  1993-10-14  |  33.7 KB  |  839 lines
  1. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  2. INTERNET DRAFT                                               Anant Kumar
  3. Expiration Date: April 12, 1994                              Steve Hotz
  4. <draft-ietf-dns-ixfr-00.txt>                                 Jon Postel
  5.                                                              USC/ISI
  6.                                                              Oct. 1993
  7.  
  8.  
  9.             Incremental Transfer and Fast Convergence in DNS
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.    This document is an Internet-Draft.  Internet-Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its Areas,
  16.    and its Working Groups.  Note that other groups may also distribute
  17.    working documents as Internet-Drafts. Internet-Drafts are draft
  18.    documents valid for a maximum of six months.  Internet-Drafts may be
  19.    updated, replaced, or obsoleted by other documents at any time.  It
  20.    is not appropriate to use Internet-Drafts as reference material or to
  21.    cite them other than as a ``working draft'' or ``work in progress.''
  22.  
  23.    To learn the current status of any Internet-Draft, please check the
  24.    1id-abstracts.txt listing contained in the Internet-Drafts Shadow
  25.    Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
  26.    munnari.oz.au.
  27.  
  28.    This Internet Draft expires April 12, 1994.
  29.  
  30. Abstract
  31.  
  32.    This memo proposes extensions to the DNS protocols to provide for an
  33.    incremental zone transfer (IXFR) procedure.  A companion mechanism,
  34.    the NOTIFY procedure, is also proposed to allow secondaries to learn
  35.    of changes to the primary database in a timely manner.
  36.  
  37. Introduction
  38.  
  39.    The last few years have witnessed an exponential growth in the number
  40.    of machines in the internet, and a corresponding dependence on DNS.
  41.    As a result, zone files have grown to near HOSTS.TXT proportions.
  42.    Each zone file is maintained at a primary server.  All modifications
  43.    to this file are made at the single site and propagated to secondary
  44.    servers using the Zone Transfer protocol [RFC 1035].
  45.  
  46.    Whenever any change is made to the zone file, the zone administrator
  47.    increments the SOA serial number.  Secondary servers poll the primary
  48.    every REFRESH interval, and if the serial number has changed, the
  49.    entire zone file is transferred.  More often than not, the change
  50.  
  51.  
  52.  
  53. Kumar, Hotz, Postel                                          [Page 1]
  54.  
  55. INTERNET DRAFT                                             October, 1993
  56.  
  57.  
  58.    made to the zone file is a very small percentage of the zone file.
  59.    Thus, an incremental transfer protocol that will propagate only the
  60.    changes to the zone file, may allow substantial savings of bandwidth
  61.    overhead.
  62.  
  63.    In addition, secondaries only check to see if they are consistent
  64.    with the primary every REFRESH period.  While setting REFRESH to be a
  65.    relatively large value reduces bandwidth overhead, there can be large
  66.    time intervals during which at least one secondary has data that is
  67.    inconsistent with the primary.  The proposed NOTIFY mechanism (where
  68.    the primary sends a message to known secondaries) facilitates fast
  69.    convergence of servers vis-a-vis consistency of data in the zones
  70.    (without requiring the overhead implied by a short REFRESH period).
  71.  
  72.    These two mechanisms can be used to reduce the bandwidth overhead of
  73.    DNS while maintaining server-to-server consistency for any particular
  74.    zone.  These mechanisms could prove particularly useful if a DNS of
  75.    the future were required to support dynamic updates (e.g. frequent
  76.    changes to a zone, possibly from multiple entities making changes by
  77.    sending "update packets").  Dynamic updates imply small database
  78.    changes, and a need for fast convergence among authoritative servers.
  79.    This memo does not specifically address a Dynamic Update scheme, but
  80.    the IXFR and NOTIFY mechanisms were designed in light of possible
  81.    requirements for dynamic update schemes.
  82.  
  83.    The following changes to the DNS protocols are required to support
  84.    the two new mechanisms: a new query type called IXFR is defined, an
  85.    opcode called NOTIFY is defined, a new RR type called ISOA is
  86.    defined, and two fields (a serial number and a flag) are added to
  87.    each resource record.
  88.  
  89. 1. Resource Record support for Incremental Transfers
  90.  
  91.    To support incremental zone transfers, an RR will now have 7 fields
  92.    as follows:
  93.  
  94.       <owner>  <ttl>  <class>  <type>  <data>  <serial number>  <Zflag>
  95.  
  96.    The current DNS mechanism does not provide a way to identify the
  97.    chronological history of the data in the zone files.  To support
  98.    incremental transfers, it is necessary to know when a resource record
  99.    was added to the database (relative to other updates).  Thus, a
  100.    serial number is associated with each resource record in a zone file.
  101.  
  102.    The "Zflag" (zombie flag) is necessary to convey incremental state
  103.    information with respect to a resource record (i.e. should the RR be
  104.    added or deleted from a secondaries zone information).  Section 1.2
  105.    details the use of "Zflag".
  106.  
  107.  
  108.  
  109. Kumar, Hotz, Postel                                          [Page 2]
  110.  
  111. INTERNET DRAFT                                             October, 1993
  112.  
  113.  
  114.    For backward compatibility reasons, the serial number and "Zflag"
  115.    will only be propagated along with IXFR transfers (further, a DNS
  116.    client has no use for serial number information at this point).
  117.    Future DNS clients might want to make use of this information, and
  118.    new query types could be defined that would return serial numbers.
  119.  
  120. 1.1 IXFR Use of RR Serial Numbers
  121.  
  122.    The RR serial numbers must be a strictly monotonically increasing
  123.    function.  This will allow servers to differentiate between two sets
  124.    of RRs: those added before a certain serial number, and those added
  125.    after a certain serial number.
  126.  
  127.    To illustrate the basic scheme, for the moment consider only the case
  128.    of adding new RRs to a zone (the more subtle cases of deletion and
  129.    modification are considered in detail below).  When an RR is added to
  130.    a zone, a new (higher) serial number is associated with the newly
  131.    added RR.  Because RR serial numbers are monotonically increasing,
  132.    servers can distinguish when an RR was added (relative to other RRs).
  133.    A scheme to conserve serial number space is described in section
  134.    1.4.1.
  135.  
  136.    The current status of zone information held at a particular server is
  137.    reflected by the highest serial number associated with the RRs of the
  138.    zone.  When a secondary requests an incremental zone transfer (IXFR),
  139.    it must send its current status (highest RR serial number) as part of
  140.    this request.  The primary server can then transfer all RR records
  141.    that have a higher sequence number; consequently, the status of the
  142.    zone information held at the primary and secondary will be the same.
  143.  
  144. 1.2 Deleting/Modifying an existing resource Record
  145.  
  146.    A modification will be treated as a deletion followed by an addition,
  147.    thus only the deletion process is described here. [NOTE: If there is
  148.    a requirement for modification atomicity, this would require a
  149.    distinct operation; this could be supported by extending the "zombie"
  150.    mechanism described below.]
  151.  
  152.    When receiving IXFR updates, a secondary must receive an EXPLICIT
  153.    notification of deleted RRs (unlike a full AXFR scheme where all RRs
  154.    are considered deleted unless refreshed).  Hence an RR cannot be
  155.    removed from the primary zone when it is deleted; instead it is
  156.    modified and used as the explicit notification (to the secondaries)
  157.    of removal.  The RR is marked as a "ZOMBIE" (using the Zflag) and the
  158.    serial number is updated as described above.  The zombie RR is kept
  159.    in memory until the primary is sure all secondaries have updated
  160.    zones to reflect the deleted RR.  When the primary is certain all
  161.    secondaries have received the notification of the deleted RR; during
  162.  
  163.  
  164.  
  165. Kumar, Hotz, Postel                                          [Page 3]
  166.  
  167. INTERNET DRAFT                                             October, 1993
  168.  
  169.  
  170.    the interim the primary, of course, does not return the deleted RR in
  171.    response to client queries.  No server should return a zombie RR in
  172.    response to a client query.
  173.  
  174.    In a sense, an IXFR contains commands of two types: one that
  175.    specifies a new RR should be added to the zone information, and one
  176.    to delete an RR from the zone.  To converge correctly, a server
  177.    receiving an IXFR must apply/process these commands (RRs and zombie
  178.    RRs) in order per the RR sequence numbers.  Note that once a
  179.    secondary applies a ZOMBIE RR to the zone information it holds, it
  180.    does not need to maintain this ZOMBIE (unless it also serves to
  181.    update other secondaries via IXFR).
  182.  
  183.    ZOMBIE RRs cannot be maintained indefinitely, because this would
  184.    cause the amount of information maintained for the zone (at the
  185.    primary) to be unnecessarily large (i.e. one does not want to
  186.    maintain some number of ADD/DELETE pairs for a particular RR that
  187.    could theoretically occur over time).  Fortunately, there is no need
  188.    to maintain ZOMBIE RRs indefinitely; they can be deleted when all
  189.    servers for a zone have been notified of the deleted RR.
  190.  
  191. 1.2.1 Mechanisms for Deleting "ZOMBIE" Resource Records
  192.  
  193.    There are multiple mechanisms that could be used to keep track of
  194.    ZOMBIE RRs and when they can be deleted.  Either or both of the
  195.    following two schemes could be used, depending on the desired
  196.    performance and overhead trade-offs.
  197.  
  198.    a. The primary can maintain information (state) about all secondaries
  199.       that normally transfer zone from it.  This will be "soft state",
  200.       implying that it can be rebuilt from scratch should the primary
  201.       server crash (the only impact being that ZOMBIE RRs may not be
  202.       deleted as soon as they might otherwise).
  203.  
  204.       Hence, for each secondary server, the primary records the last
  205.       serial number it transferred (on recovering from a crash, this
  206.       number will be set to 0).  When the minimum of these serial numbers
  207.       (for all servers of a particular zone) is greater than the serial
  208.       number on a ZOMBIE RR entry, that ZOMBIE RR can be removed.
  209.  
  210.    b. This scheme requires that secondary servers may sometime be
  211.       "forced" to take an AXFR rather than an IXFR.  A primary maintains
  212.       all RRs within "N" serial numbers of the zone's current serial
  213.       number (highest valued RR serial number);  ZOMBIE RRs with serial
  214.       numbers lower than (current_serial_number - N) are deleted.
  215.  
  216.       Any secondary server that requests a serial number smaller than the
  217.       primary's (current_serial_number - N), must AXFR instead of IXFR.
  218.  
  219.  
  220.  
  221. Kumar, Hotz, Postel                                          [Page 4]
  222.  
  223. INTERNET DRAFT                                             October, 1993
  224.  
  225.  
  226.       The primary will send an AXFR reply (in response to the IXFR) and
  227.       the secondary is expected to be able to parse either IXFR or AXFR
  228.       responses to its original IXFR query. It should be built to parse it
  229.       either way.
  230.  
  231.       This scheme is designed to be more efficient (and simpler) than the
  232.       alternative where the primary refuses the IXFR and the following events
  233.       happen:
  234.  
  235.            client: request(IXFR)
  236.            server: refuse(IXFR)
  237.            client: request(AXFR)
  238.            server: send(AXFR)
  239.  
  240.    Either or both of these schemes, (a) and (b), could be used, and this
  241.    can be an implementation-specific decision so long as the servers can
  242.    interoperate.  Scheme (a) requires no additional protocol
  243.    interaction, but all [secondary] servers must accommodate a "you
  244.    asked for an IXFR *but* here is an AXFR" if different implementations
  245.    are to interoperate.
  246.  
  247.    While a primary could implement either approach, one should see an
  248.    advantage by implementing both.  The "soft state" method (a) will
  249.    allow ZOMBIE RRs to be deleted as early as is possible, and the
  250.    "refused IXFR" method (b) will place a bound on the amount of memory
  251.    required by the primary (useful in the case where a secondary is out
  252.    of touch for very long periods of time).
  253.  
  254. 1.3 The Role of the SOA Serial Number
  255.  
  256.    Since IXFR-capable servers are likely to be used together with older
  257.    servers during a transition period (of unfortunately indefinite
  258.    length), the SOA serial number functionality must be preserved for
  259.    backward compatibility.  This implies that the SOA serial number must
  260.    be changed each time the zone is updated.  The simplest solution is
  261.    for the SOA serial number to reflect the highest RR serial number.
  262.  
  263.    This issue is not difficult in the context of simply accommodating
  264.    incremental zone transfers, since a zone file (and SOA serial number)
  265.    will necessarily be updated when RRs are added, deleted, or modified.
  266.    However, there is other ongoing work that is addressing mechanisms
  267.    for dynamically updating zone information; it would be an advantage
  268.    if the IXFR scheme considered such mechanisms, and was designed to
  269.    accomodate the additional complexities introduced by dynamically
  270.    updated zone information.
  271.  
  272.    If the use of dynamic updates are ignored, the SOA serial number
  273.    could be updated in the same manner as it is today.  In fact, the
  274.  
  275.  
  276.  
  277. Kumar, Hotz, Postel                                          [Page 5]
  278.  
  279. INTERNET DRAFT                                             October, 1993
  280.  
  281.  
  282.    manually-updated SOA serial number could be assigned to each new,
  283.    modified, or deleted/zombie RR.  Other implementation-specific
  284.    schemes could be used to derive SOA serial numbers and maintain the
  285.    relationship between SOA serial number and RR serial numbers.
  286.  
  287. 1.3.1 SOA Serial Numbers in light of Dynamic Updates
  288.  
  289.    The IXFR scheme essentially obsoletes the function of the SOA serial
  290.    number, replacing it with finer-granularity serial numbers applied to
  291.    RRs (this is especially true if dynamically updates to the zone are
  292.    made).  The highest-valued RR serial number now reflects the status
  293.    of the zone information.  At this point, the question is unresolved
  294.    as to how the SOA serial number should be treated.
  295.  
  296.    Without going into specifics, the crucial point is that zone
  297.    information will not always change due to a zone file update.
  298.    Further, RR serial numbers will be assigned dynamically which must be
  299.    reflected in SOA serial number (for interoperability).
  300.  
  301.    An implication (which may be disturbing to the old guard of DNS
  302.    administrators) is that SOA serial number will not be updated
  303.    exclusively in the zone file.  To preserve zone integrity, the
  304.    changes made dynamically must take precedence over manually-updated
  305.    SOA serial numbers; consider the case of a manually-updated SOA
  306.    serial number being less than that required by the number of dynamic
  307.    updates.
  308.  
  309.    Summary: The specifics of this issue can be resolved in separately
  310.    from the dynamic update effort.  However, the IXFR scheme should be
  311.    aware that the use of the SOA serial number is likely to change as
  312.    follows:
  313.  
  314.    (1) The function of the SOA serial number is replaced by the highest
  315.        RR serial number.  SOA serial number must also reflect changes to
  316.        the zone for backward compatability; some mapping from RR serial
  317.        numbers to SOA serial is required (the simplest being that they
  318.        are the same).
  319.  
  320.    (2) A manual update of a zone file cannot specify an SOA serial number
  321.        which conflicts with (is smaller than) SOA serial number that
  322.        reflects dynamic changes to the zone.
  323.  
  324. 1.4 New RR Serial Number Generation
  325.  
  326.    This is an implementation specific issue, as long as the the function
  327.    is monotonically increasing, and the constraints imposed by the
  328.    relationship between RR serial numbers and the SOA serial number are
  329.    met (see Section 1.3).  One obvious function is to maintain a
  330.  
  331.  
  332.  
  333. Kumar, Hotz, Postel                                          [Page 6]
  334.  
  335. INTERNET DRAFT                                             October, 1993
  336.  
  337.  
  338.    sequence number counter, which is updated each time a new RR (or
  339.    ZOMBIE RR) is added (see section 1.4.1 for a variation of counter-
  340.    based sequence number generation).
  341.  
  342.    A simple alternative (especially in light of dynamic updates) is to
  343.    use a timestamp (seconds since the epoch) as determined at the
  344.    primary server.  The primary advantage (other than simplicity) is
  345.    speculative; if the actual time of update is available to clients,
  346.    the DNS system, or network administrators, it might serve some useful
  347.    function in the future (e.g. perhaps network administrators can
  348.    identify irregularities in a zone by examining RR serial number and
  349.    applying heuristic that takes into account expected turn-over rate
  350.    for the zone).
  351.  
  352.    Section 1.3 implies that manually-updated SOA serial numbers may not
  353.    be possible in the future, hence the semantics attached to them by
  354.    many administrators today (i.e. YYMMDDHH) may also be less clear.
  355.    The use of timestamp-based serial number might be an appropriate
  356.    replacement.
  357.  
  358.    The disadvantage of timestamps is that they might not be compatible
  359.    with the existing serial number space.  A future timestamp might be
  360.    much smaller (numerically) than a serial number associated with a
  361.    given zone today.  This could, of course, be resolved by the rather
  362.    drastic measure of shutting down all servers for a domain, deleting
  363.    the zone backup files from all secondaries and starting afresh, with
  364.    a new serial number space based on timestamps.
  365.  
  366. 1.4.1 Reducing Sequence Number Rollover
  367.  
  368.    If a simple counter-based sequence number is used (rather than
  369.    timestamp-based), the sequence number does not necessarily have to be
  370.    updated each time a new RR is added.  A scheme to conserve the use of
  371.    serial number space could be based on whether other servers have
  372.    received updates recently:
  373.  
  374.            If (zone transferred by anybody)
  375.                    set(NewNumNeeded);
  376.  
  377.    and when a new RR is added:
  378.  
  379.            If (NewNumNeeded) {
  380.                    currentserial++;
  381.                    reset(NewNumNeeded);
  382.            }
  383.            RR->serialNum = currentserial;
  384.  
  385.    Thus, all RRs added between any two transfers get the same serial
  386.  
  387.  
  388.  
  389. Kumar, Hotz, Postel                                          [Page 7]
  390.  
  391. INTERNET DRAFT                                             October, 1993
  392.  
  393.  
  394.    number, thereby saving some amount of serial number space.  Note that
  395.    when an RR is modified, this is actually a "delete" and an "add"
  396.    which must be done in the correct order.  If the ordering is based on
  397.    sequence number, then the simple scheme above must accommodate this
  398.    additional constraint.
  399.  
  400. 2. ISOA, the new RR type.
  401.  
  402.    System administrators (for whatever reason) might not be comfortable
  403.    depending exclusively on incremental transfer to maintain zone
  404.    consistency.  If this is the case, it can be resolved by configuring
  405.    periodic "checkpoints" where full zone transfers are done.
  406.  
  407.    Thus, after REFRESH seconds, secondaries will use IXFR to transfer
  408.    incremental data.  In addition, secondaries will do a complete zone
  409.    transfer every XXFRTIME seconds (typically at least an order of
  410.    magnitude greater than REFRESH) using the method described later in
  411.    this document (section 4).
  412.  
  413.    To specify the XXFRTIME, an additional RR type is defined (so we are
  414.    backward compatible with existing DNS implementations). It has
  415.    symbolic name "ISOA" and numeric value xxx. The data section of the
  416.    ISOA record will look as follows:
  417.  
  418.                                        1  1  1  1  1  1
  419.          0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  420.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  421.        |                    XXFRTIME                   |
  422.        |                                               |
  423.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  424.  
  425.    This RR might, in the future, be expanded to contain other fields and
  426.    we are considering giving it a more flexible structure to accommodate
  427.    for those changes.
  428.  
  429. 3. The Actual Mechanism
  430.  
  431.    An IXFR query packet will, necessarily, contain the highest RR serial
  432.    number the secondary last saw.  Thus, the DNS IXFR query packet will
  433.    look like this.
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445. Kumar, Hotz, Postel                                          [Page 8]
  446.  
  447. INTERNET DRAFT                                             October, 1993
  448.  
  449.  
  450.                                        1  1  1  1  1  1
  451.          0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  452.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  453.        |                                               |
  454.        /                     QNAME                     /
  455.        /                                               /
  456.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  457.        |                  QTYPE = IXFR                 |
  458.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  459.        |                     QCLASS                    |
  460.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  461.        |             SECONDARY SERIAL NUMBER           |
  462.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  463.  
  464.    Note that QNAME, QTYPE and QCLASS are exactly as for any other query
  465.    type.  SECONDARY SERIAL NUMBER is the serial number the secondary
  466.    must convey to the primary so the primary can send it all entries
  467.    updated since that serial number was seen.
  468.  
  469. 3.1 The Client Side
  470.  
  471.    The client (secondary) sends an SOA query to the server (primary) and
  472.    compares the serial numbers.
  473.  
  474.            If (current > latest) {
  475.                    signal a possible error;
  476.                    QUIT;
  477.            }
  478.  
  479.            If (current == latest) {
  480.                    exit gracefully;
  481.            }
  482.  
  483.            If (current < latest) {
  484.                    transmit_IXFR_query(current_serial_number);
  485.                    destroy_zone_file();
  486.                    receive_IXFR_response(&buf);
  487.                    update_zone_data(hashtab);
  488.                    recreate_zone_file(backup_zone_file);
  489.            }
  490.  
  491.    Note that we destroy the zone file before we actually attempt to
  492.    receive any data from the server. We do this since otherwise, if we
  493.    receive data and crash before we are able to update our zone file,
  494.    the primary will believe that we have the latest data while when we
  495.    actually recover, we will not. The "recreate_zone_file()" operations
  496.    needs to be atomic or at least, if the server crashes midway through
  497.    the operation, it should be able to detect this when restarting.
  498.  
  499.  
  500.  
  501. Kumar, Hotz, Postel                                          [Page 9]
  502.  
  503. INTERNET DRAFT                                             October, 1993
  504.  
  505.  
  506.    Thus, by this destruction, we ensure that we either have the latest
  507.    data or that we have nothing.  This is of special importance here
  508.    since if we do not destroy the zone file and the client crashes after
  509.    it completes the transfer but before it can update the zone file, we
  510.    have a problem.  The server believes the client has the updated data
  511.    (if it keeps soft state) while the client actually does not.
  512.  
  513.    Thus, when we actually recover from the crash, we initiate a full
  514.    zone transfer from the server.
  515.  
  516. 3.2 The Server
  517.  
  518.    The server follows this simple algorithm when processing IXFR
  519.    queries.
  520.  
  521.            current_serial_from_client -> csn;
  522.            Record (csn, soft_state_structure);
  523.  
  524.            If (csn == SOA_serial) {
  525.                    send blank response;
  526.            }
  527.            If (csn < SOA_serial - N) {
  528.                    refuse IXFR.. or send AXFR response;
  529.                    exit;
  530.            }
  531.  
  532.            for (each entry in zone file)
  533.                    if(csn >= entry_serial_number) continue;
  534.                    else add entry to IXFR packet;
  535.            endfor;
  536.  
  537.            Transmit IXFR packet to client.
  538.  
  539.    Thus, a server sends incremental transfers only if the csn from the
  540.    client falls within N of the present value of the SOA serial number.
  541.    It could either refuse a response if it falls beyond N in which case
  542.    the client must be prepared to initiate an AXFR.  Alternatively, the
  543.    server could send the AXFR packet instead and the secondary must
  544.    expect and be able to interpret that packet.
  545.  
  546. 4. XXFR
  547.  
  548.    Once every XXFRTIME (section 2), the IXFR query packet will be:
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557. Kumar, Hotz, Postel                                         [Page 10]
  558.  
  559. INTERNET DRAFT                                             October, 1993
  560.  
  561.  
  562.                                        1  1  1  1  1  1
  563.          0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  564.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  565.        |                                               |
  566.        /                     QNAME                     /
  567.        /                                               /
  568.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  569.        |                  QTYPE = IXFR                 |
  570.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  571.        |                     QCLASS                    |
  572.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  573.        |                   SERIAL = 0                  |
  574.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  575.  
  576.    Note that the SECONDARY SERIAL NUMBER field equals the value "0".
  577.  
  578.    This prompts the server to send an IXFR packet that contains all the
  579.    zone data, i.e. it is the equivalent of the AXFR.  The system could
  580.    use this to synchronize complete zone files at regular XXFRTIME
  581.    intervals.
  582.  
  583. 5. NOTIFY
  584.  
  585.    Currently, a secondary always waits "REFRESH" seconds before polling
  586.    the primary for any changes in the zone.  If a primary makes any
  587.    changes (that may be rather important) and wants that all secondaries
  588.    reflect these changes immediately, the primary has no means of
  589.    talking to the secondaries.
  590.  
  591.    A mechanism must be available to notify the secondary that it might
  592.    benefit from a zone transfer, right away if possible.  We propose a
  593.    new opcode, "NOTIFY", to fulfill exactly this need.
  594.  
  595.    When the database is updated, the primary sends a NOTIFY packet to
  596.    the secondaries.  This packet contains the SOA record for the zone
  597.    and informs the secondary that it might benefit from a transfer.  The
  598.    secondary can choose not to transfer, if it sees a heavy load at that
  599.    moment.  The notification could be turned on, on a per zone basis,
  600.    and might need a new bootfile parameter (NOTIFY/NONOTIFY) with the
  601.    primary/secondary entry.
  602.  
  603.    This mechanism will be particularly useful in dynamic update
  604.    situations where servers might need to converge to a common state,
  605.    fast.
  606.  
  607.    The NOTIFY packet looks like this:
  608.  
  609.  
  610.  
  611.  
  612.  
  613. Kumar, Hotz, Postel                                         [Page 11]
  614.  
  615. INTERNET DRAFT                                             October, 1993
  616.  
  617.  
  618.                                        1  1  1  1  1  1
  619.          0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  620.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  621.        |                      ID                       |
  622.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  623.        |QR| "NOTIFY"  |AA|TC|RD|RA|   Z    |   RCODE   |
  624.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  625.        |                    QDCOUNT = 0                |
  626.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  627.        |                    ANCOUNT = 1                |
  628.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  629.        |                    NSCOUNT = 0                |
  630.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  631.        |                    ARCOUNT = 0                |
  632.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  633.        /                                               /
  634.        /                   SOA RECORD                  /
  635.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  636.  
  637.    A mix of polling (current mechanism) and low-priority interrupts from
  638.    the primary may be considered as the mechanism for zone transfers.
  639.  
  640. 5.1 Unregistered Secondaries
  641.  
  642.    The primary server must be aware of the presence of all secondaries,
  643.    including those that aren't registered ("registered" servers are
  644.    those servers whose names are returned by DNS in response to an NS
  645.    query for that zone), in order to send them NOTIFY messages.  Note
  646.    that this information is also needed if the primary is maintaining
  647.    "soft state" (per the mechanism in section 1.1.2).
  648.  
  649.    Once again, there are two different means of doing this:
  650.  
  651. a. Automatic Registration
  652.  
  653.    Any entity that initiates any kind of transfer (IXFR/AXFR) is
  654.    identified as a potential candidate for notification and for the
  655.    purpose of keeping soft state (as described in section 1.1.2).  The
  656.    IP address of this entity may be recorded against the zone it
  657.    transferred.  Old entries (more than some number of REFRESH periods
  658.    old, say 10*REFRESH) may be timed out).
  659.  
  660. b. "my-secondaries"
  661.  
  662.    We keep a list of "my-secondaries" servers that are not advertised
  663.    via the DNS but are known servers for our domain (possibly serving
  664.    local resolvers).  Since the system administrator typically knows
  665.    about unregistered secondaries, this merely formalizes their
  666.  
  667.  
  668.  
  669. Kumar, Hotz, Postel                                         [Page 12]
  670.  
  671. INTERNET DRAFT                                             October, 1993
  672.  
  673.  
  674.    existence.  Such secondaries are usually local machines, mostly
  675.    time-sharing machines on a campus or organization premises (within
  676.    the domain) that serve as name servers for local queries, keeping the
  677.    load on the registered secondaries, small.
  678.  
  679.    We propose an entry in the bootfile of each server that expects to
  680.    see IXFR queries from other servers that reads:
  681.  
  682.    my-secondaries    zone          server1, server2, ....., serverN
  683.  
  684.    This is a list of secondaries that would normally transfer zone from
  685.    this server.
  686.  
  687.    This entry may immediately follow the entry that says,
  688.  
  689.    primary         zone            datafile
  690.    or
  691.    secondary       zone            primary
  692.  
  693.    Thus, "my-secondaries" servers are associated with a given zone and
  694.    could transfer from either a secondary or the primary server.  Thus,
  695.    a secondary that serves as source for zone data for other secondaries
  696.    needs to maintain such a list, like the primary.
  697.  
  698.    In either case, please note that we do not address the issue of
  699.    cached data at other servers.  TTL values could be used to ensure
  700.    that data is not cached for longer than it is likely to stay valid.
  701.  
  702. 5.2 Timing and Security issues.
  703.  
  704.    Notification procedure necessitates that we ensure the following:
  705.  
  706.    a. There must be a minimum time between notifications.  This prevents a
  707.       malicious primary from bogging the secondary down, with back-to-back
  708.       notifications.  The secondary must maintain a timer (optionally) to
  709.       enforce such restrictions.
  710.  
  711.    b. A secondary must transfer zone within a maximum interval (existing
  712.       REFRESH mechanism should suffice).  This ensures the state is not
  713.       inconsistent for more than a fixed maximum interval.
  714.  
  715.    c. Modification Notification should be accepted only if coming from
  716.       primary or the server you normally transfer from.  A malicious network
  717.       entity could pose as a primary and transfer incorrect data to you.
  718.       This does not really solve the problem of impersonation since a
  719.       masquerading entity could just as well act as the primary when
  720.       sending the NOTIFY message.  This just provides an additional hurdle
  721.       so somebody actually sending you a NOTIFY does need to impersonate
  722.  
  723.  
  724.  
  725. Kumar, Hotz, Postel                                         [Page 13]
  726.  
  727. INTERNET DRAFT                                             October, 1993
  728.  
  729.  
  730.       the primary.
  731.  
  732.    d. When accepted, zone should be transferred only from primary or the
  733.       server you normally transfer from.
  734.  
  735. 6. Performance Issues
  736.  
  737.    DNS, like any other replicated, distributed system, has various
  738.    parameters that can be tuned to get the desired nature of
  739.    performance.  For example, a shorter REFRESH cycle ensures a faster
  740.    convergence among authoritative servers, at the cost of extra network
  741.    bandwidth used in transferring zone data.  Thus, system
  742.    administrators tune this figure to the desired mix of consistency and
  743.    bandwidth usage.
  744.  
  745.    Similarly, the TTL associated with each RR presents a trade-off
  746.    between how often you query an authoritative server and how current
  747.    your data is.  A low TTL would keep the data current at the cost of
  748.    extra network traffic while a high TTL conserves bandwidth but allows
  749.    for the data to be inconsistent.  System administrators balance
  750.    between the two requirements and choose a reasonable TTL.
  751.  
  752.    Similar figures in the above scheme, such as the frequency of NOTIFY
  753.    acceptance, the TTL of dynamic data and possibly the number of
  754.    secondaries allowed, present trade-offs that need to be made to tune
  755.    performance.  A higher rate of NOTIFY acceptance will imply greater
  756.    network traffic but very speedy convergence.  A lower figure will
  757.    conserve network bandwidth but will allow for data to be inconsistent
  758.    for longer.
  759.  
  760.    A single server, serving a zone will imply instantaneous convergence
  761.    but will provide very low availability and reliability.  This might
  762.    be alright for a low traffic volume zone.
  763.  
  764.    We do not, by way of the IXFR and NOTIFY mechanisms, hope to provide
  765.    servers that converge instantaneously with minimal traffic.  Studies
  766.    in the future will show how effective these mechanisms will be and
  767.    how best the various parameters can be used to tune the performance.
  768.  
  769. 7. Acknowledgements
  770.  
  771.    We express our sincere thanks to Clifford Neuman, Masataka Ohta, Don
  772.    Lewis, Philip Wood and Paul Vixie for their comments on earlier
  773.    versions of this draft.
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781. Kumar, Hotz, Postel                                         [Page 14]
  782.  
  783. INTERNET DRAFT                                             October, 1993
  784.  
  785.  
  786. 8. Authors' Addresses:
  787.  
  788.    Anant Kumar, Steve Hotz, Jon Postel
  789.    <anant, hotz, postel> @isi.edu
  790.  
  791.    USC Information Sciences Institute
  792.    4676 Admiralty Way
  793.    Marina Del Rey CA 90292-6695
  794.  
  795.    Phone:(310) 822-1511
  796.    FAX:  (310) 823-6714
  797.  
  798.  
  799. This Internet Draft expires April 12, 1994.
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837. Kumar, Hotz, Postel                                         [Page 15]
  838. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  839.